אסטרטגיות לניהול הבדיקות 

אסטרטגיות לבדיקות תוכנה - איך להביא את המוצר למצב איכותי אידאלי

המשחק והשחקנים

מי מאיתנו, מנהלי הבדיקות, לא קיבל החלטה קשה בשבועיים האחרונים? למעשה, כל תגובה או יוזמה של מהלך שלנו, היא צעד במשחק כאשר האתגרים הם ברורים: אין זמן לבדוק הכל, אין דרישות מסודרות, אין סביבת בדיקות נקייה ובטוחה, ונוסף על זה - אחד הבודקים שלנו בדיוק היום לא מרגיש טוב. כמובן שלמרות כל התנאים הללו, אנחנו עדיין נדרשים לייצב גרסה מצויינת, וכתפיינו גדלות למימדים עצומים, לעיתים גם מבלי שנרגיש בכך.

הרבה מנהלי בדיקות מתלוננים על אי יכולת להביא את המוצר לאיכות טובה בזמן ככ קצר, ובשילוב אחד מהתנאים שהזכרנו קודם.

במאמר הזה, נציג מספר אסטרטגיות שיכולות לפתור את הדילמה, ובעיקר - להרגיע את מנהלי הבדיקות, ובמיוחד את הלקוח.

חלופות נפוצות

כמעט בכל מחזור חיים של תוכנה, אנו נתקלים בבעיה הזו. או שאין דרישות בכלל, או שהם לא מעודכנות, או שאין יכולת לפתח בזמן שהוגדר את הדרישות כמות שהן, ולכן מנהלי הפיתוח מחליטים לעשות  Phase 1 ו  phase 2  כשזה בד"כ אומר : אנחנו נעשה מה שנצליח לעשות, ומה שלא? .... נדבר על זה כבר ...

במצב כזה, מנהלי הבדיקות נדרשים לבצע 2 משימות בלתי אפשריות (כמעט): ניהול מסמכי הבדיקות ברמה מקיפה ומעמיקה (כל הדרישות מכוסות בבדיקות), וניהול סיכונים לקראת הרצת הבדיקות (בעיקר לפני Release).

ובכן, איך אפשר לבצע את המשימות הללו בתנאים בעייתיים ככ?

אסטרטגית הדגל האדום

מנהלי בדיקות רבים בוחרים באסטרטגיית הדגל, שמשמעותה היא העברת האחריות לממונים: הרמתי דגל למנהל שלי- שאינני יכול לבצע את הבדיקות בצורה הזו, ואינני יכול לקחת אחריות מקיפה על המוצר. ובכן ידידי המנהל, משלמים לך בדיוק עבור לקיחת האחריות הזו. זוהי אומנם דרך מקובלת מאד, אך היא לבטח לא מבטיחה מוצר טוב יותר, או העלאה בשכר....

אסטרטגיית זרימה

אנחנו רואים מנהלי בדיקות ש זורמים עם הבעיות, ומתנהלים איתם. המפתח והמאפיין סיכמו בינהם על שינוי בטלפון? או.קיי - אני מעביר את התושב"ע לבודקים וממשיך הלאה. מכאן, הדרך של הדרישה להפוך לבדיקה ממצה ונכונה - רחוקה מאד.

למעשה, במקרים כאלה, אין עקיבות מראש בין דרישות לבדיקות, ומסמכי הבדיקות אינם ממצים. גם כאן, מנהלי הבדיקות מסתפקים בבינוניות ומתקשים לבצע ניהול סיכונים נכון, ובוודאי ניהול מעקב דרישות.

אסטרטגית שפיות לקוח

אסטרטגיה זו, היא מוכוונת צרכי לקוח. היא טוענת שמה שצריך להיות לנגד עיני מנהל הבדיקות זה מה הכי חשוב ללקוח, בסופו של יום. אסטרטגיה זו, אמנם לא עומדת בתקנים שלומדים בהכשרות למיניהם, אך היא מבטיחה לקוח מרוצה. היא נותנת מקום מכובד למתודולוגיות ולעקיבות, וגם לתכולות חדשות, אך המרכיב המרכזי בשיקולי המנהל הוא מדד שביעות רצון הלקוח. למשל: ללקוחות בד"כ (בין אם הלקוח הסופי הוא יוזר באתר, או ממשלה או בנק) חשובים דברים שמנהלי פיתוח דוחים לסוף, כגון: מערכת יציבה, ביצועים טובים, נוחות משתמש (user friendly) ומערכת 'סקסית'. כשמנהל הבדיקות לוקח את הנושאים האלה ומתמקד בהם, ומכווין את אנשיו להתרכז בזה, הוא מרוויח בסוף 'לקוח מרוצה'. נכון, זה דורש עבודה רטרואקטיבית בנושא עדכון מסמכי הבדיקות, ויותר מזה, רתימה של מנהלי הפיתוח לתקן באגים מסוג זה בעדיפות עליונה. אבל את העבודה הסזיפית והקשה של עדכון מסמכים, ויצירת מטריצת עקיבות, יהיה לו זמן לעשות בדיעבד. אחרי שהגרסא בייצור (production). לאסטרטגיה זו יש ערך מוסף אישי אדיר כשמתבוננים בתהליך שאנשי הבדיקות עוברים. איש הבדיקות מבין הרבה יותר טוב את צרכי הלקוח, את הפונקציות המשמעותיות שהוא רוצה לראות, ומתעדף את הבדיקות והבאגים בהתאם. בגרסה הבאה שהוא ייבדוק יתכנן - בדיקות השפיות שלו ייראו אחרת. הם ייתמקדו בדברים הנכונים, ללא צורך בעדכונים שוטפים בעקבות שינויי אפיון. כי הלקוח לא משנה את דעתו כל יומיים. הוא יודע מה הוא רוצה לראות, והוא יודע שהוא רוצה שזה יעבוד פשוט, קל מהר ונח. כמובן שיש להבחין בין הלקוח לבין המאפיין (האחרון נוטה לשנות את דעתו לעיתים קרובות). הלקוח לעומתו, לא.

בהצלחה!